Add nvm_get_arch overwrite #3251
Conversation
There was a problem hiding this comment.
Sorry for the review delay.
Adding a new hook is always dangerous, so I'm going to have to think hard about it. To be clear, the only expected use case here is to use it in combination with unofficial builds?
Either way, to add it, it would indeed need tests and a readme mention, but probably best not to do that work until I'm sure it's something I'd be willing to merge.
|
I was also hoping this will allow people to use NVM on more niche systems like mentioned in the referenced issue without the need of going through PRs and further expanding the code that determines which architecture to use. |
|
That kind of flexibility is a double-edged sword; i'd rather add new systems explicitly so that it's properly supported versus having a bunch of users with setups I'm totally unaware of, that have a subpar experience. |
|
Jumped on today to write a PR for this very use case. Think it's going to become more and more useful as OSs move past glib2.26 and enterprise users are left behind stuck on old gear. I know Amazon Linux 2 is affected which is quite a big user base. People, including myself, are doing horrible workarounds, like installing via https://repost.aws/questions/QUvkkhY--uTiSDkS6R1jFnZQ/node-js-18-on-amazon-linux-2 I see this hasn't moved on in 3 months - I'm happy to contribute if I can help get this feature implemented? |
|
@SamFarrington if it's just AWS i'd expect amazon to solve the problem for you. |
ljharb
force-pushed
the
master
branch
2 times, most recently
from
c6cfc3a
to
c20db2a
Compare
|
Instead of the generic escape hatch, is there a more targeted fix specifically for AWS users we could pursue? |
|
centos is about to EOL so probably not worth pursuing this at least for the case of just centos. Users who temporarily need to support Node 18+ before migrating away from centos could just fork or use this nvm branch. |
|
Something being EOL isn't relevant; lots of people are stuck on EOL things. |
Addresses #3041
This bypasses the "guess" work for which "architecture" of node.js to use.
It was already possible to specify a custom mirror like mentioned here #3175 (comment), but without the ability to specify the suffix, its use cases are very limited.
One example for this addition is to use Node.js v18+ on centos7 which requires the glibc-217 compatible version. Now possible to install like this
NVM_NODEJS_ORG_MIRROR=https://unofficial-builds.nodejs.org/download/release/ NVM_NODEJS_ORG_ARCH=x64-glibc-217 nvm install 18Before spending time on adding README, etc. what do you think of this approach?